The World Wide Web is the Internet's multimedia information retrieval system. In the web environment, client machines communicate with web servers using the Hypertext Transfer Protocol (HTTP). The web servers provide users with access to files such as text, graphics, images, sound, video, etc., using a standard page description language known as Hypertext Markup Language (HTML). HTML provides basic document formatting and allows the developer to specify connections known as hyperlinks to other servers and files. In the Internet paradigm, a network path to a server is identified by a Uniform Resource Locator (URL) having a special syntax for defining a network connection. So called web browsers, for example Netscape Navigator (Netscape Navigator is a registered trademark of Netscape Communications Corporation) or Microsoft Internet Explorer (Microsoft and Internet Explorer are trademarks of Microsoft Corporation), which are applications running on a client machine, enable users to access information by specification of a link via the URL and to navigate between different HTML pages.
When the user of the web browser selects a link, the client machine issues a request to a naming service to map a hostname (in the URL) to a particular network IP (Internet Protocol) address at which the server machine is located. The naming service returns an IP address that can respond to the request. Using the IP address, the web browser establishes a connection to the server machine. If the server machine is available, it returns a web page. To facilitate further navigation within the site, a web page typically includes one or more hypertext references (“HREF”) known as “anchors” or “links”.
A portal application is typically a web application which aggregates content from various different sources and presents it within a portal web page, and can have personalization features to provide customized content to users. The portal application can provide a gateway to one or more backend software applications and is often provided on a separate portal server.
The portal server typically arranges web content into a portal page containing one or more portlets. A portlet is a web component, managed by a portlet container, which processes and generates dynamic web content. This content, often called a fragment, can be aggregated by the portal application with content from other portlets to form the portal page. The content generated by a portlet may vary from one user to another depending on the user configuration for the portlet.
The portal application provides a navigation framework for a set of web pages arranged on the server in a hierarchy. This framework provides a user interface allowing navigation through the hierarchy of pages that are available on the server. The user interface providing this navigation is known as a theme. Each page may contain zero or more portlets, the page arrangement being predetermined and constructed using design or administration tools.
With a standard server-side portal application, a client web browser is used to view the aggregated output of several portlets on a single page.
Users interact with the portlets causing events to be generated. The portal application receives an event and determines if the event is associated with any of the portlets associated with the portal page. If an event is associated with a portlet on the portal page, the portal application requests the portlet container to invoke that portlet to process the event. Once the portlet has processed the event (in an event processing phase), a rendering phase begins, wherein the portlet generates a content fragment to be included in a new portal page. Additionally, all other portlets on the requested portal page refresh and pass a content fragment to the portal application.
The portal application packages each portlet content fragment in a portlet window adding a title and control buttons to each window. This is sometimes called ‘wrapping’ each supplied content fragment, and the additional markup used to wrap the content fragment is called a ‘skin’. The skin may include control buttons which may be used, for example, to place the portlet into a specific mode such as edit or configure, or to change the display state of the portlet into a maximized or minimized visual state, such as in a common windowing system.
Next, the portal application aggregates the portlet windows into a complete portal page, for sending to the client. The web browser renders the portal page on a display screen of the client.
It should be understood that the event processing phase executed by a portlet can be slow (e.g., if access to remote systems is required, if access to legacy systems is required, etc.). Also, the rendering phase cannot begin until the event processing phase has completed and a portal page for rendering on a client cannot be sent until the rendering phase for all portlets has completed. Thus, the completion time for the entire process (i.e. event processing phase, rendering phase and rendering on the client) is governed by the slowest portlet. This is frustrating for a user because a lengthy time period can pass before the user can view results associated with their request.
One solution to this problem is to use an HTML inline frame (IFRAME) to embed portlet content. An IFRAME has its own URL and can therefore load and be forced to refresh independently of the portal server (and therefore, independently of other portlets). However, a portal application loses control of the portlet whose content is embedded in the IFRAME. Furthermore, currently, support for IFRAMES by browsers is limited.